MySQL パラメータチューニング innodb_log系
前提
ログファイルが小さいと、ダーティページを保持できる期間が短くなるので、ログファイルサイズも大きくしておいた方がいい
innodb_log_buffer_size
hr.icon
前提知識として軽く
ディスク上のredo log ファイルに書き込む前のメモリバッファ領域のサイズを指してる。
このバッファのデータはコミットもしくは定期的にディスクにフラッシュされるのだが...
コミットされる前にバッファ領域が埋められると、すぐディスクにフラッシュされてしまう。
根拠となる資料が現状ないが、多分そんな挙動だと思う..onigiri.w2.icon
（ちなみに...設定「innodb_flush_log_at_trx_commit」で、コミット時にフラッシュするかどうか決めれる）
そうなると無駄なディスクIOが発生することになるので、避けたいところではある。
増やす必要があるかどうか見極める方法
サーバー変数「Innodb_log_waits」の値が大きい時！！！
Innodb_log_waits：The number of times that the ログバッファーが小さすぎるため、続行する前にフラッシュするために待機が必要だった回数。
この回数が多いならログバッファは小さいと言える。
増やす際の注意点
例に漏れず、メモリサイズを大きくする場合は、他のメモリ領域とのバランスもちゃんと見てね。
独立してないよ。
innodb_log_file_size, innodb_log_files_in_group
hr.icon
前提知識として軽く
データベースの整合性を保つためのコア的な存在、それがRedoログ。 こいつには全てのトランザクション内容が順次書き込まれていく。
こいつは、データの整合性を保つために存在していることから、こいつに書き込めなくなった場合、データ書き込みができなくなることを意味する。
つまり、こいつがデータでいっぱいになったら、一時書き込みが中断される。
中断されて、バッファプールのダーティページを一度ディスクに書き込んで、書き込んだデータに関するトランザクションをRedoログから削除して...っていう作業が必要なのである。 こいつが大きければ、いちいち容量をあけるためにチェックポイントを高頻度で実行しなくて良くなる。
ダーティページも思う存分貯めれて、書き込みIOが減る。
なので、やっぱり大きくしておきたいよね。
log_file_sizeを増やす必要があるかどうか見極める方法
あんまわからんけど、書き込み処理が多いワークロードなら、試す価値ありかも。
ここはベンチマークして確認するしかないか？
ただ、バッファプールを大きくするなら、redoログファイルサイズも大きくしないと狭いで。
注意点
ログファイルサイズが大きすぎると、Redoログの量多くなりすぎて、クラッシュリカバリに時間かかるようなるから気をつけて。
innodb_log_files_in_groupの注意点
ログファイルを多くしすぎると、ログファイルの回転にオーバーヘッドあるという噂あり。